The present invention relates to the field of networked applications and, more specifically, to federation of composite applications.
FIG. 1 (Prior Art) shows an overview of the components that build up the prior art application infrastructure (AI) 11 and system architecture within an overall portal system 10. The application infrastructure includes templating application infrastructure (TAI) 13, composite application infrastructure (CAI) 15, component registry 27, and portal handler 29.
TAI 13 can handle the templates in the system and the creation of new composite applications. CAI 15 can handle the application instances 19 during runtime and can manage connections and the data flow between the components of an application. The component registry 27 can manage the business components installed in the system. The portal handler 29 can be a specific local component that manages any portal related artifacts 8, such as pages and/or portlets for the application infrastructure in the portal. The portal handler 29 can be used by the instantiation component 17 to create such artifacts during the creation of a new composite application.
As shown, TAI component 13 manages the templates 23 in the system which contains references to instantiable components in a local list of components 27. As an example, a template for shopping applications can consist of a reference to a document library component which is used to hold the available goods and their descriptions, a shop portlet that lets clients process actual shopping transactions, an invoice business component that handles the payment process, and a blogging component that allows clients to comment on their satisfaction.
The TAI component 13 also creates application instances from templates via an instantiation component 17, which creates separate instances of the referenced business components, typically by creating or copying individual configurations for these components such that multiple application instances can be created from the same template without interfering with each other.
For the above mentioned sample template, the instantiation 17 can, among other things, create an individual storage compartment in the document library, an individual configuration of the invoice component referring to the bank account, and an individual configuration for the shop portlet. The configuration for the shop portlet can be set up to display goods from the created document library and can be used to delegate payment processing to the created invoice component instance.
In particular, the instantiation 17 creates the necessary portal artifacts such as pages that allow users to interact with the created composite application. This is typically done by employing a specific handler 29 that creates portal artifacts 8 and links them with the business components of the application.
The created composite application instances 19 hold a context 25 that lists the component instances that make up the composite application.
FIG. 2 (Prior Art) shows an overview of the storage components involved in the portal architecture 10 that comprises deployment related code in a deployment component 14 and a runtime environment in one or more runtime containers 12 where the deployed components are executed. For the composite application context deployed artifacts can include application components stored in a component registry 18 and/or templates stored in a template catalog 20. This data can be referenced by the application's instance specific data 16.
Prior art composite applications are a key concept of the prior art “Service Oriented Architecture” (SOA). They allow end-users to assemble business logic out of a set of given components without programming by simply defining some meta information, such as configuration data and application structure.
Prior art composite applications are supported for example by the prior art IBM WEBSPHERE PORTAL and other known products.
A key element in supporting any desired services oriented architecture is giving business analysts the ability to implement complex logic using pre-built components. The components can be assembled to a coherent “composite application”, which can be developed, deployed, managed, and used as a single entity, rather than managing the included components individually.
Prior art composite applications are executed in a runtime container, which adds capabilities, such as management of application specific access control, templating, communities, roles, and the like.
While servlet/portlet containers in prior art focus on individual components and how they render User Interface (UI) information, the composite application container is adding management capabilities in prior art. This concept is, for instance, introduced by the prior art IBM WEBSPHERE PORTAL.
One conceptual disadvantageous limitation which exists is that all components need to be executed on the same server and in the same application runtime container. This disadvantage requires all components to be used within a composite application to be installed on one and the same local server system. If remote information is needed, a local “proxy” business component needs to be written and integrated in the application. The prior art proxy component imports such remote information by implementing Web services. For example, a request is sent to a remotely installed application, which receives and processes the request and sends back a response which is processed by a control container of the composite application.
A prior art composite application consists of independent components which are set together to build a union which performs some predefined business tasks as a whole. Disadvantageously, all components need to be installed at one and the same application server.
With reference to FIG. 3 (Prior Art) showing a prior art system architecture for prior art use of composite applications, a complex composite application can span multiple systems, denoted as 32, 34 and 36, for example a system A having a portal composite application infrastructure 31, system B 34 being a Systems Applications and Products (SAP) system, and system C being for example a DOMINO server system, for example for an application of LOTUS NOTES. In each of the shown systems 32, 34 and 36 a plurality of components are installed, symbolized by the puzzle-like parts in each system, wherein each component runs in its own runtime container.
According to this prior art there is no possibility to virtually execute the components in a single composite application runtime environment. Instead, programmers need inevitably to write “gluecode” for the business components which connect the various systems and the interaction of the components. This can be an error-prone work, which is additionally quite complicated and requires much programming knowledge, in particular knowledge about Systems A, B, C runtime environments. This gluecode forms a remote access, for example, from System A to System B and System C in order to cooperate and communicate with the components implemented there. The mainly used implementation is based on Web requests or on remote procedure calls.